The invention relates generally to computer information security and the Internet, and more specifically to methods that permit one or more third-party agents to access customers' private personal and financial data or other confidential information on the world-wide-web. The invention was originally designed as a method for banks and bank customers to mutually approve one or more third party agents (such as aggregators, for example) to access customer confidential data via the Internet. It is also applicable, however, in any situation involving computers where an agent's computer or computers act as an intermediary between computers of two other parties and where access to certain information is to be limited, whether or not the information is confidential.
The Consumer Problem
When the World Wide Web (“the web”) was invented in 1990, security was not a major concern because it was primarily used to share scientific research. The initial concept was for unlimited, open, public access to documents. As the web became popular, however, the need for security increased. Web sites developed schemes with usernames and passwords to protect confidential web pages. And, in 1995, SSL encryption became the standard method to protect confidential data transmitted over the public Internet. By 1999, consumers started to become confident in the security of Internet transactions, and Internet commerce became commonplace. Millions of consumers regularly made purchases, paid bills and performed common banking and brokerage transactions using the Internet.
Today, a typical consumer might have access to dozens of secure web sites for shopping and financial services. Because each site has a unique look and feel, customers must learn how to navigate each individual site. Each site also has a unique security identification and authentication scheme, forcing each customer to keep track of dozens of usernames and passwords, PINs and code words. These factors may be confusing and frustrating for consumers. So, while the Internet revolutionized the way consumers access information, taking advantage of it is often difficult and cumbersome. Obtaining a consolidated view of a customer's Internet or on-line accounts could easily require hours of manual effort, working at a computer, visiting many web sites.
The Aggregator Solution
An aggregator is a web service that consolidates a consumer's financial and personal information and presents it in a concise, easy-to-read fashion. An aggregator accesses shopping and financial service web sites to extract customers' data and repackages that data for presentation on the aggregator's web site. After enrolling with an aggregator, customers only need to learn how to navigate the aggregator's web site. Furthermore, customers must remember only one username/password combination, instead of dozens.
The enrollment process typically involves setting up a username and password to access the aggregator's web site. This username/password becomes a very powerful “master password” because it gets linked to the customer's other accounts and passwords. In addition to creating master passwords, customers also enter details about each bank, brokerage and shopping web site they want the aggregator to access on their behalf. Details include usernames, passwords, account numbers and other secret or confidential information required to access aggregated web sites. (Not all aggregators know how to access all financial and shopping web sites, so the aggregator must support the bank, brokerage and shopping web sites a customer intends to use.) Once the aggregator has the information necessary to access all of a customer's accounts, however, the aggregator will work behind the scenes on the Internet to assemble the details about the customer's personal financial life or other confidential information.
When a customer visits the aggregator's web site, the aggregator will typically display a list of bank, credit card, brokerage, shopping and other financial accounts, along with associated balances, in a concise, consistent and consolidated fashion. The aggregator's site usually also has features to “drill down” into details about any account, showing transactions, history and trends. If the aggregator offers bill payment features, customers can also view on-line versions of bills and statements, including transaction details. Many aggregators also allow customers to schedule bill payments—where the aggregator moves money from customers' bank accounts to vendors or other accounts either electronically or by mailing actual checks. Since an aggregator may track uncleared transactions, the financial information kept by an aggregator may be more up to date than customer's account data at each bank, brokerage or vendor. An aggregator makes customers' on-line financial life much easier to manage. The aggregator is, in effect, a personal financial agent on the Internet.
How Do Aggregators Work?
Many aggregators use a technique known as “screen scraping” to access customers' information at various financial and shopping web sites. During screen scraping, the aggregator simulates a human and Internet browser accessing each web site. A computer program takes the place of a keyboard and mouse by supplying the expected input. Much like a human reading results on a screen, the computer program “reads” and stores the information returned by each aggregated site.
Screen scraping is not a perfect technology, however. If a web site changes its appearance or process flow, the aggregator may not be able to accurately obtain (or scrape) the information from the web site. Aggregators must constantly monitor aggregated web sites in an attempt to keep their computer programs current with each site.
In contrast, some aggregators have tightly coupled relationships with various financial institutions. This enables them to use more advanced techniques such as Interactive Financial Exchange (IFX), Open Financial Exchange (OFX) or eXtended Markup Language (XML), for example, to efficiently transfer account information. However, these techniques have not yet been widely adopted.
Risks of Aggregation
Many consumers recognize the benefits provided by aggregators, but feel uncomfortable providing aggregators unlimited access to passwords and other private information. If the security at an aggregator's web site is compromised, unscrupulous parties could steal customers' private and confidential information and passwords.
When banks and other commercial web sites created their username/password schemes, they intended that only the consumer associated with each username know the secret password. In many cases, banks don't even store actual passwords. Instead, they store only a mathematically hashed value based on the password, which is enough information necessary to detect a valid password. In other words, many banks don't actually know a password, but they can determine if the customer really knows it. Storing password information in this manner reduces the likelihood of password theft by bank employees. This method also helps prevent password theft by Internet hackers.
When consumers provide passwords to an aggregator, they reduce the security and safety of their passwords because they are stored at an aggregator's computing facility in a reproducible form. Even if the aggregator stores encrypted passwords, this is less secure than a mathematical hash, because, unlike a bank, the aggregator can reproduce the original passwords. An aggregator's unscrupulous employee or an Internet hacker could exploit this risk and steal passwords.
Banks, brokerages and retail companies, for example, created their web sites with the intent that actual customers would access their sites. They didn't intend for aggregators' automated systems to extract customer data. The web sites' auditing and record logging mechanisms were originally intended to track actual customers initiating transactions. Commercial web sites need a way to audit and record accesses by aggregators distinctly from actual customers. These audit mechanisms should have a way to determine if a customer actually approved each aggregator's access.
If a customer discontinues the use of an aggregator, he or she would request the aggregator to disable their username and clear their personal information. However, this does not guarantee that the customer's confidential information has been removed. For a variety of legitimate reasons, or in the event of error, the aggregator might retain records of the customer's associated accounts, usernames and passwords. This retention might be temporary, but could even be permanent. The customer has no method to detect when an aggregator accesses his accounts, so they cannot easily feel confident that all access has been terminated.
The risks described here, plus financial liability and other regulatory risks, are roadblocks to widespread acceptance of aggregators by consumers, commercial web sites and government regulators.
Public Key Cryptography and Digital Certificates
Much of public key cryptography relies on unique properties of extremely large prime numbers (hundreds or more digits long) and a technique patented in 1983 by R. L. Rivest, A. Shamir, and L. M. Adleman. This technique, commonly known as RSA encryption (named for its inventors), allows any general-purpose computer to generate a pair of mathematically related numbers, known as encryption keys (or just “keys”), within a few seconds. Typically, one of the keys is called the private or secret key because the key owner must protect and secretly store the only copy of the private or secret key. The other number is called the public key because it can safely be shared with anyone.
Although the RSA methods can easily generate a key pair within a few seconds, the process to reconstruct a key pair is extremely difficult. If one key in a pair is lost, it could take the world's fastest computers many years to decompose the known key and recalculate the lost key. This disparity in decryption is the strength of public key cryptography. If someone has your public key, it is very difficult (almost impossible) for him or her to determine your private or secret key. If you have someone's public encryption key, you can use RSA's encryption techniques to encode a message or file that only that person can decrypt and read. The message recipient must have the private key (which is associated with the public key) and use RSA's decryption techniques to decode the message.
Conversely, if someone uses his or her private or secret key to encrypt some data or its digest, then anyone with access to that person's public key can decrypt the data or its digest back to its original form. Assuming that the originator protects his private or secret key, nobody else could have sent the original encrypted message—in effect a mathematical signature proves who originated the message. (Within the computer security industry, this exemplary security device is commonly known as a digital signature.)
The public and private or secret keys complement each other. If one of the keys encrypts (or locks) some data, the other complementary key decrypts (or unlocks) the data. Each customer, commercial web site and aggregator must have a unique public and private key pair. Rather than inventing methods to manage the storage of private keys and sharing of public keys, this invention relies on the existing public key infrastructure (PKI). With PKI, when an entity (person or company) creates a key pair, they register the public key with a certifying authority (CA). The CA verifies the identity of the entity and issues a digital certificate, which has been digitally signed by the CA.
The digital certificate serves as a tamper-resistant electronic identification document for an entity. The digital certificate includes the entity's public key. (Only the entity that generated the key pair should have access to the associated private or secret key.) Much of the software required to manipulate and store digital certificates and associated keys already exists as commercially available software. Most Internet web browsers and web servers have the capability to store digital certificates and keys, and software libraries, such a RSA's CryptoJ can perform public key cryptography. It is expected that this invention will be implemented using tools such as these, among others.
Although the technology exists, and the software is readily available, the use of digital certificates has not yet been widely adopted by consumers. By the year 2000, the United States federal government and many states approved the use of digital certificates and digital signatures as acceptable authentication mechanisms for public-to-government transactions. As public and commercial acceptance of digital signatures become commonplace, it is expected that most commercial institutions will either issue or otherwise assist customers to obtain digital certificates.
SSL Encryption
The Secure Sockets Layer (SSL) protocol was developed by Netscape Communications, Inc. as a way to securely move data over a public network, notably and typically over the Internet. SSL uses public key cryptography, specifically RSA's encryption methods, for example, to establish a secure “session” between two computers connected via the TCP/IP protocol. Public keys, usually obtained from digital certificates and associated private or secret keys may be used to identify (authenticate) one or both computers in a TCP/IP conversation. Once an SSL session is established, it is very difficult (almost impossible) for a third party to eavesdrop and examine the data flowing between the end computers. This invention assumes that SSL encryption, or similar encryption protocols among those readily known by those skilled in the art, will be typically used for all secure communications between customers, aggregators and commercial web sites.
Optionally, SSL authentication may also be used to verify the identity of one or both parties involved in each communication. If both parties use public keys from digital certificates, for example, and associated private keys in conjunction with SSL to authenticate their identities with each other this is commonly referred to as SSL mutual authentication. If only one party uses a private or secret key and digital certificate for one end of an SSL session, this is commonly referred to as SSL single-end authentication.
Although this invention works best with SSL mutual authentication, it may also be used with SSL single-end authentication or even if SSL authentication is not used at all. In these cases, the parties must select some other form of verification or authentication (e.g., usernames and passwords), which should occur immediately after each SSL session is established. This invention requires that the parties involved in electronic communications, for example, have somehow verified or authenticated their identities with each other, using SSL authentication, for example, or similar techniques well-known to those skilled in the art.
Other known encryption/decryption methods will also occur to those skilled in the art, including those using symmetric, asymmetric, message digests (mathematical hashes), or other encryption schemes (including those using multiple-use or one-time use keys), for example.
Using the present invention, a tamper-resistant security document, such as an electronic document, known as a ticket, is created and approved by two consenting parties to allow a third party (or even more parties) to access private and confidential personal and financial data on the Internet (world-wide-web). The electronic ticket or other types of security documents can also have a limited lifetime, allowing the consenting parties to control the third party's duration of access.
Some of the exemplary features, objects or advantages of the present invention include:                (a) to provide an electronic document (ticket), for example, that proves that two or more parties consent to allow a third party (or more parties) secure verified access to confidential information;        (b) to create an electronic document (ticket), for example, that is very difficult (almost impossible) to forge;        (c) to create an electronic document (ticket), for example, that is very difficult (almost impossible) to modify without the creator's consent;        (d) to create an electronic document (ticket), for example, that is only useful to the intended parties—a stolen ticket can't be successfully used by a thief,        (e) to create an electronic document (ticket), for example, that eliminates, or least substantially minimizes, damaging security consequences if it is lost or stolen;        (f) to create an electronic document (ticket), for example, that only needs to be stored by a single party;        (g) to create an electronic document (ticket), for example, with a limited lifetime—the ticket can't be used after it expires;        (h) to create an electronic document (ticket), for example, whose expiration date and time (“expiration time”) is agreed upon by all parties;        (i) to create an electronic document (ticket), for example, that can be used by a third party an unlimited number of times (or alternately, if desired in particular situations, for a specified limited number of times) during the ticket's lifetime;        (j) to create an electronic document (ticket), for example, containing a serial number allowing the ticket's approval and usage to be monitored and recorded for auditing purposes;        (k) to create an electronic document (ticket), for example, that allows the consenting parties to insert optional information into the ticket for subsequent, future usage; and/or        (l) to create an electronic document (ticket), for example, that may be safely substituted in situations where a traditional password would normally be used.        
Possible further objects and advantages are to provide an electronic document (ticket) that can be initiated by any of the three or more parties, that allows customers, for example, to use third party agents to access confidential financial and personal information in a safe and secure and verifiable manner without requiring customers to reveal confidential passwords, and that also utilizes existing Internet technologies. Other objects, advantages and features of the invention will readily occur to those skilled in the art from the following description and appended claims, taken in conjunction with the accompanying drawings.